home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 98 / Skunkware 98.iso / src / mail / smail-3.2.tar.gz / smail-3.2.tar / smail-3.2 / README < prev    next >
Text File  |  1996-06-14  |  10KB  |  228 lines

  1. #ident    "@(#)smail:RELEASE-3_2:README,v 1.10 1996/06/14 19:01:56 woods Exp"
  2.  
  3.  
  4.        This is Smail (RELEASE-3_2) by the Smail development group.
  5.  
  6.  
  7. INTRODUCTION
  8.  
  9. This release of Smail is based entirely on Smail-3.1 by Ronald S. Karr
  10. and Landon Curt Noll.  The majority of sources under this directory are
  11. copyright by the authors, whereas code under the ./pd/ subdirectory is
  12. available in the public domain.  Code in the ./contrib/ directory is
  13. owned by the contributing authors, who should be consulted if you have
  14. any questions about distribution or usage restrictions.
  15.  
  16. See the file COPYING for information on copying restrictions that apply
  17. to all files in the release other than files in the contrib and pd
  18. directories.
  19.  
  20. See the file INSTALL for information on how to configure and install the
  21. Smail software.  PLEASE CHECK ALL THE SECTIONS OF THIS FILE.  In
  22. particular, some later sections describe system and environment specific
  23. configuration details that you should be aware of, if they apply to your
  24. situation.
  25.  
  26. Users of Smail-3.1 releases should review the CHANGES file, to see what
  27. has changed or to see if some previously encountered problems have been
  28. fixed.  You *will* have to re-write your conf/EDITME files.
  29.  
  30.  
  31. OBTAINING NEW VERSIONS OF SMAIL
  32.  
  33. The official distribution can be obtained from ftp.uu.net with FTP using
  34. the following URL:
  35.  
  36.           ftp://ftp.uu.net/networking/mail/smail/
  37.  
  38.  
  39. CHANGES TO SMAIL DEVELOPMENT PROCESS
  40.  
  41. In June 1994, Ronald S Karr, who had almost single handedly run the
  42. Smail-3 development up to that time, decided that he was unable to keep
  43. up with the work required to keep smail development going.  An ad-hoc
  44. development team was subsequently set up, initially with the task of
  45. getting a smail 3.1.29 release built which fixes the security problems
  46. found in smail 3.1.28, and to continue future Smail-3 development.  It
  47. was also intended that a group will work on development of further fixes
  48. and changes for Smail-3 and a hopeful re-write as Smail-TNG.
  49.  
  50. Since the release of smail 3.1.29, Nigel Metheringham was responsible
  51. for a great deal of work in creating many development releases, and
  52. incorporating numerous changes and fixes from the ad-hoc team.
  53.  
  54. With the release of Smail-3.2, a new group is being formed, made up of
  55. past participants and new, who will all have direct access to the
  56. official Smail-3 sources repository.  Please see the section below
  57. regarding bugs and patches for further information.
  58.  
  59. These development groups are intended to be small enough to work
  60. quickly, and large enough that the work can be spread out to prevent
  61. single person overload.  If you are interested in joining the groups
  62. then please contact the bugs address given below.  We are always
  63. interested in receiving bug fixes and/or new features patches whether or
  64. not you are a member of the development group -- again see below for how
  65. to do this.
  66.  
  67.  
  68. KNOWN PROBLEMS IN SMAIL RELEASE-3_2
  69.  
  70. There are a small number of things that are known to cause problems, but
  71. which have not been addressed in the current release.  Here is a summary
  72. of the serious problems:
  73.  
  74.  *  Spill-over spool directories don't always work correctly, so don't
  75.     use them.  A spill-over directory is a second directory listed in
  76.     the spool_dirs configuration variable.
  77.  
  78.  *  Smail does not always limit the size of mail messages.  There is a
  79.     configuration parameter for this, but it is currently ignored
  80.     in all cases except for ESMTP configurations, where the SIZE option
  81.     is specified to the remote system with the maximum accepted message
  82.     size.
  83.  
  84. Please consult the ToDo file for a list of the known minor problems.
  85.  
  86. In addition, there are some features that Smail really should have, and
  87. that are intended for a future release.  Some of these are:
  88.  
  89.  *  The ability to deliver multiple messages per connection to a
  90.     destination host.  The proposed solution for this also involves a
  91.     separate Smail daemon for delivery, similar to the organization of
  92.     the Zmailer program by Rayan Zachariassen of UUNET Canada and
  93.     formerly of the University of Toronto.  Dan Bernstein's qmail; as
  94.     well as the AT&T Research UNIX, SysVr4 native, and Plan 9 mailer,
  95.     sometimes known as UPAS; also have similar designs.
  96.  
  97.  *  Smaller mail queuer programs (i.e., rmail, rsmtp), that do not have
  98.     all of Smail linked into them.  This would make smail more palatable
  99.     on smaller systems.
  100.  
  101. Please consult the PROJECTS file for a list of other important things.
  102.  
  103.  
  104. SUPPORT FOR JANET MAIL
  105.  
  106. Smail now contains limited support for JANET mail (the reverse-order
  107. domain system used in the United Kingdom).  Complete support is
  108. available from Philip Hazel <ph10@cus.cam.ac.uk>.  The smail3
  109. distribution provides only those hooks that must be in the smail
  110. binary itself.  Send mail to Philip for more information.  If you
  111. are not in the UK, please ignore this paragraph: you don't want to
  112. know.
  113.  
  114.  
  115. FUTURE SMAIL RELEASES
  116.  
  117. If anybody would like to take on the large task of making Smail a
  118. leaner, cleaner, and more adaptable program, please let us know.  If
  119. nobody ever comes forward, then we will probably have to consider the
  120. full rewrite dead, and continue hacking on the current sources.
  121.  
  122. I am interested in volunteers for large, and medium-sized tasks.  If you
  123. are interested, please send us e-mail.
  124.  
  125. The next major release of of Smail (if there is one! ;-) will have been
  126. converted to use the GNU Autoconf (and Automake) utilities for system
  127. configuration.
  128.  
  129. Smail will no doubt be popularly known as Smail-3 for a long time to
  130. come.  However it is expected that Smail will follow the Berkeley CSRG
  131. version numbering scheme for future releases.  We will increment the
  132. third number (3.7, 3.7.1, 3.7.2, etc) whenever we generate a release of
  133. bug fixes (what might traditionally be also known as a "patch" release),
  134. and increment the second number, or the minor release number, (3.7, 3.8)
  135. whenever we add any new features or make other user-visible changes, and
  136. lastly we'll increment the first number, or the major release number,
  137. (3.9, 4.1) whenever we make major or architectural changes.  We'll also
  138. throw in a smattering of GNU-isms too -- the alpha- and beta-test
  139. releases of upcoming proper releases will have a ".80" or ".90"
  140. (respectively) appended to the current release number (3.7.1.80,
  141. 3.7.1.81, 3.7.1.90, 3.7.2; or 4.1.80, 4.1.81, 4.1.82, 4.1.90, 4.1.91,
  142. 4.2).  You'll note this effectively caps the maximum patch level, or
  143. minor release number, ceiling at ".79", and limits the number of alpha
  144. releases to 10.  Unfortunately it does not limit the number of beta
  145. releases!  ;-)
  146.  
  147.  
  148. GENERAL ACKNOWLEDGEMENTS
  149.  
  150. The Smail-3.2 release now exists, thanks to the efforts of Chip
  151. Salzenberg, Nigel Metheringham, Greg A. Woods, and a cast of others.
  152.  
  153. These original Smail-3.1 acknowledgments from Ronald S. Karr:
  154.  
  155.     Some smail3 users go back quite a ways and have provided
  156.     invaluable help, patches, and comments over the years.  Here's a
  157.     few that I can remember: Andy Beals, Mark H. Coburn, Karl
  158.     Denninger, Mark Hartman, Shane McCaran, Tim Mitchell, Gordon
  159.     Moffett, Lyndon Nerenberg, Dave Rand, Andy Rundquist, Chip
  160.     Salzenberg, Johan Vromans, Lauren Weinstein, Syd Weinstein, Bill
  161.     Wisner, and Jon Zeeff.
  162.  
  163.     A special thanks to Landon Curt Noll <chongo@toad.com> who
  164.     started me on the road of post-college life and caused me to
  165.     write smail in the process.  He also helped design and implement
  166.     the first several versions.  Without him, smail3.1 certainly
  167.     would never have been written.
  168.  
  169.     A special thanks also to Larry Auton, who wrote smail2.5.
  170.     Without him, Smail3.1 would have, at the very least, been called
  171.     something else.  He also provided valuable encouragement and
  172.     comment during the earlier phases of smail design and
  173.     development.
  174.  
  175.  
  176. BUGS, COMMENTS, AND PATCH SUBMISSION
  177.  
  178. Please generate and send bug reports and/or fixes by using the smailbug
  179. utility (a customised version of GNATS send-pr) included with Smail.
  180.  
  181. There are now two discussion lists started by Lyndon Nerenberg
  182. <lyndon@cs.athabascau.ca> and now maintained by Daryl Campbell
  183. <daryl@cs.athabascau.ca>:  smail3-users and smail3-wizards.
  184.  
  185. To subscribe to either of these lists send mail to either:
  186.  
  187.     smail3-users-request@cs.athabascau.ca
  188.  
  189. and/or to:
  190.  
  191.     smail3-wizards-request@cs.athabascau.ca
  192.  
  193. I do not have any connection with this list, other than the fact that I
  194. maintain the software that it discusses.  So, please don't send list
  195. change requests to me.
  196.  
  197. Please send questions, comments, or anything else you have to say either
  198. to me, or to the discussion groups.
  199.  
  200. I vastly prefer receiving bug fixes and enhancements that are clearly
  201. differentiated.  I don't always know what to do with large patches that
  202. contain many bugs and enhances folded into the same context diffs.
  203. Please try and keep it to one fix or enhancement per patch.  If your
  204. change modifies the external interface of smail -- i.e. more config
  205. options, command-line switches, new programs, etc., then please also
  206. include patches for the manual pages and documentation.  Patches should
  207. ideally be in context or unidiff format, and should have "Index:" lines
  208. to specify the file to be patched.  Finally, *please* include ChangeLog
  209. style entries to describe your changes.  Incomplete patches will greatly
  210. lower their priority for consideration.
  211.  
  212. [ Again, generating patches with your local changes is quite easy if you
  213. employ CVS as a source control tool. ]
  214.  
  215. If you are a past Smail-3 maintainer, and/or you've recently supplied a
  216. number of good patches, and you are willing to volunteer some time to
  217. help with the future maintenance of Smail-3, your application can be
  218. considered for membership in the Smail-3 developers group.  This
  219. membership will allow you access to the master CVS source repository and
  220. our GNATS bugs database.  Please see the charter for the development
  221. group in the file ./Smail3-devel.
  222.  
  223. -- 
  224.                             Greg A. Woods
  225.  
  226. +1 416 443-9665            VE3TCP            robohack!woods
  227. Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
  228.